Aminet 1 (Walnut Creek)

home *** CD-ROM | disk | FTP | other *** search

/ Aminet 1 (Walnut Creek) / Aminet - June 1993 [Walnut Creek].iso / aminet / comm / fido / wpl_intro.lzh / wpl.readme < prev next >

Wrap

Text File | 1993-02-24 | 78KB | 1,699 lines

Welmat Programming Language - WPL --------------------------------- WPL is the new interpreted language for writing network mailers and other telecomunications utilities. The language is designed to be very extendable by third party developers, and makes use of a grouping of shared libraries with a standardized interface. The 'application' previously called 'Welmat' and this language have a few things in common. Firstly, the origional 'Welmat' code was used as a shell during the development of this language so that things could be upgraded in stages. At this point the majority of the code has been re-written, and most of what used to be called 'WELMAT' is now housed in an XPR library called 'xprfts.library' that is an optional external transfer protocol. Secondly, the development philosophy and distribution licence for the program called 'WELMAT' is being kept. This new language is licenced under the GNU public licence and is aimed at providing very powerfull and configurable tools to allow the users to determine their own personal networking environments. Thirdly, the name 'WELMAT' is being kept as the name of the support conference, it is the 'W' in 'WPL', and there is a hope that a 'WCompile' program to make use of the old V0 Welmat config files will be written. At last, many of the origional Welmat enthusiests are getting involved with the development, beta testing and support of this new language and related tools. The similarities between WPL and the application called WELMAT pretty much end there. This new language is just that : A LANGUAGE. With this language comes many different 'levels' of users ranging from people who would need to be 'C' and Assembly programmers, to people who might not even know how to run a CLI command: a) WPI (Welmat Programmers Interface) developers - People who would make use of 'wpl.library' and other tools common to the WPL envirionment in language extension libraries, etc [Note: Any of the old WELMAT programs that talked to the 'WelmatMAST' message port (wctl, WNotify, wabort, etc), as well as any flow.library supporting utilities do not work in conjunction with WPL.] b) WPL developers - People who write mailers, BBS's, terminal packages or other applications in the new WPL language. These people could also be the authors of programs such as WCompile, WelmatPrefs, etc which would in one way or another generate a 'WPL script' that would contain the functionality of the 'application'. These developers might also include the various REXX and FPL developers who would be making use of the various language gateways to these telecomunications tools. c) While not really 'WPL specific', any author working on an XPR supporting file transfer protocol, expecially those that are working on libraries that might conform to the future 'XPR 3.0' proposals would be able to make use of WPL as their host, and any WPL developers would be able to make use of these file transport protocols in their applications. Anyone interested in this level of development are strongly encouraged to get connected to the XPR mailing list for future XPR development discussion (More information provided in the 'XPR' section of this readme). d) While again not 'WPL specific', any author working on xferq.library supporting file request handlers, tosser/scanners, outbound list managers, etc would also be able to make use of WPL as their host. Regardless of whether an author wishes to use WPL itself, adding support for XferQ is extremely highly reccomended as it will likely become the future standard in outbound queue management for the Amiga. [information available from David Jones (dej@qpoint.ocunix.on.ca)] e) User level - This would constitute the majority of people using WPL based systems. These people would need no knowledge of any tools other than the programs that will be generating the 'WPL scripts' that will be their mailer. People in this group could be using mailers that are configured much like the old Welmat V0 config files, or with newer systems such as the proposed WelmatPrefs program (A program that will make setting up a network mailer as simple as setting up ones screen preferences). *NOTE*: WPL is an internal language that will likely be used by less than 10% of the users that will be making use of the new environment. Unless you are an extreme power user, it is reccomended that you wait to do any mailer beta testing until some of the configuration editors are being written. Learing WPL,WPI,etc is not required, nor even reccomended for the majority of users!!! It is my hope that in the future the various 'user levels' will be able to have their own support people. I myself would love to be able to write networking tools that I would then support to people at the first and second level. These people in turn would write 'user applications' that they would support to the actual users as they would be more familiar with configuration issues with their tools than anyone else. This would allow for much more people to be involved, and for much better user support for all the various types of users that exist. One of the problems, for instance, with the current 'WELMAT' support conference is that people at the 'User Level' are almost shut out by the people at the 'WPL developer' level. For this reason I am in the process of setting up an alternate WPL-PROGRAMMER support conference so that another conference WPL-_APPLICATION will be left for 'User Level' support of the various applications that will emerge. -------------------------------------------------------------------------------- WPL Support ----------- Before moving into discussing how WPL itself works, I thought I should mention methods of asking questions. I find that with a new language that there is a fairly high initial learning curve, but that things get easier once the initial problems are worked out. Since WPL is a mailer language that can be used by people in many different types of networks, support exists in many forms: Fidonet Email Support: Russell McOrmond@fidonet#1:1/139 Internet Email Support: aa302@freenet.carleton.ca Old Fido support Echo : WELMAT Note: The support conference for the old program 'WELMAT' is only temporarily being used until the new support conferences can be added to the backbone. I wish to eventually vacate this conference, and leave it available for people to actually discuss the old 'Welmat' program. Programmer support echo: WPL-PROGRAMMER [yet to be added to backbone] Programmer support list: wpl-programmer@alfred.ccs.carleton.ca Requests to join the list: wpl-programmer-request@alfred.ccs.carleton.ca This conference is aimed at the more technical aspects of the use of WPL as a language, and as an expandable library system. It is requested that support questions of users not developing in WPL, C, assembly, ETC to put their questions into WPL-APPLICATION. User support echo: WPL-APPLICATION [yet to be added to backbone] User support list: wpl-application@alfred.ccs.carleton.ca Requests to join the list: wpl-application-request@alfred.ccs.carleton.ca This conference is aimed at the 'Users' of WPL based application scripts, GUI configuration editors, and other such things. This is an open forum between the WPL developers and the users of their applications. It is requested that this conference remain as non-technical as possible. Various WPL representatives also frequent the Fidonet echomail conferences AMIGA_NET_DEV and AMY_POINT, as well as the usenet conferences comp.sys.amiga.datacomm and alt.sys.amiga.uucp -------------------------------------------------------------------------------- What is required to run WPL? ---------------------------- Required: Before attempting to set up WPL, the following should be located. - WPL requires AmigaDOS 2.04 (Kickstart V37) or higher. - The main binary for wpl (currently 'wpl.bin', soon wpl.library). (Magic name only available in support conference currently) - xferq.library (Now in public testing) - xprzedzap, xprfts and any other XPR's you require for the protocols you wish to run. - A configuration program generator, or knowledge of WPL in order to write your own configuration script. Optional: - If you are using a Tosser/Scanner that uses 4-D .OUT files, JBundle is reccomended for compression. - If you are using a Tosser/Scanner that uses .FLO files, some sort of 'conversion' utility is needed. One has not yet been written to my knowledge. - If you wish to support file requests, XFreqSH, or some XferQ supporting file request handler is needed. - If you wish to support UUCP, Login is reccomended. - A nodelist 'lookup' program is required for nodelist support. Support programs for both traplist.library and IGEN's 'nodelist.library' exists. - to write XferQ supporting scripts or programs, the full XferQ documentation is a must. - To edit your outbound queue, XTool is currently reccomended. -------------------------------------------------------------------------------- General WPL script information ------------------------------ A WPL script is a text file that is read in line by line by a routine that will try to analyse the line into a valid WPL statement. When these lines are parsed, they are parsed into a format of: [label:] command [parameter] [parameter] [parameter] ... where the 'label' is a string of alpha-numerics a maximum of 30 characters in length (and is terminated by a colon ':'). A command is any WPL command that is known to the parser at the time the file is being parsed, and the parameters are a given number of text strings where the number is specific to each WPL command. Before looking up the command it first checks if the first character is a ';' (semicolon) or a '#' (octothorp). If it is, the rest of the line is 'thrown out' as being a comment. (NOTE: If there was a label on the line before the comment, the label is valid). A blank line, lines with comments, or parameters beyond the number required by the function are just thrown out as 'useless information' and are not kept by the WPL parser. Strings within WPL are a generic concept used by every function in the language. When I say a function takes '3 parameters' I mean that it takes three of these 'WPL strings'. Now, since the space character is used to separate parameters, if you want to send an actual 'space' character, you must put your string within quotes. Now that you're using the double quote " character to form the string, if you want to put an actual QUOTE character within a string, you must escape it by doing \" (Yes, just like what was done in WCompile's config files). Now that you have this escape character, if you want to put a '\' in the string, you must escape the escape character and use \\. Some other special escape characters exist: \n - Newline (Same as Linefeed) \r - Return character \### - send the Octal (base 8) character given by the three digits following the slash. Note: single-tic ' characters have absolutely not significance to WPL strings at all, and are added un-touched to the string. As you know they DO have a significance to REXX so are usefull to avoid having to 'escape the quote' when sending messages to REXX. If a variable is being read as a boolean, it is considered true if it's 'numeric value' is not '0', or if the first character is upper or lower case 't'. Otherwise, it is considered false. TRUE == -1 == 1 == truck == 9999 FALSE == 0 == Charles == false ------------------------------------------------------------------------------ Here is a very general rundown of the commands currently available within WPL. I will be trying to keep this updated and as accurate as possible, so let me know about any incorrect, or un-clear commentary. I will later on be basing the WPL programmers manual on this text. The format of this command list gives the following information: Command Name, Number of argument STRINGS - WPL variables read - WPL variables modified - General description of the command. ------------------------------------------------------------------------------ The first type of commands are the control commands. These commands are only available from within a WPL script, and are not available via the REXX port. These are also the only commands that do not follow the same rules for their parameters. Unlike other commands, a variable is a hard-coded text value and cannot include any type of variable. Also note that all labels are currently *case insensitive*. NOTE: If a label is not found, this statement will just continue with the next statement. A program called 'WLint' will detect and warn about these types of things, but one should be carefull until that program is written. Return 0 - No WPL variables read or modified This command will return to whatever called the sub-routine. If the sub-routine was called by the 'SubJump' command, it will continue with the statement following the 'SubJump'. The last 'RETURN' statement within a WPL script will cause the SLAVE to exit. TrueReturn 0 - Reads the $(RC) variable as a boolean. - Does not modify any variables. This will do a return only if the $(RC) variable is True. FalseReturn 0 - Reads the $(RC) variable as a boolean. - Does not modify any variables. This will do a return only if the $(RC) variable is False. Jump 1 - No WPL variables read or modified This command will search for the given label and will unconditionally jump to that location in the script. No return address is saved. TrueJump 1 - Reads the $(RC) variable as a boolean. - Does not modify any variables. Will only jump if the $(RC) variable is True. FalseJump 1 - Reads the $(RC) variable as a boolean. - Does not modify any variables. Will only jump if the $(RC) variable is False. SubJump 1 - No WPL variables read or modified This command will search for the given label and will unconditionally jump to that location in the script saving the return address. When the next 'return' statement is hit, control will return to the statement immediately following the SubJump command. TrueSubJump 1 - Reads the $(RC) variable as a boolean. - Does not modify any variables. Will do a SubJump call only if the $(RC) variable is True. FalseSubJump 1 - Reads the $(RC) variable as a boolean. - Does not modify any variables. Will do a SubJump call only if the $(RC) variable is False. ---------------------------------------------------------------------------- The following commands are both within a WPL script, and via the REXX port of a specific slave. All parameters can be built up of fixed text and any type of variable. With the proposed new 'wplcmd.library' and 'wplext.library' function libraries, I am attempting to organize commands into one one of the two libraries. The 'wplcmd.library' is the required library, and will house all the commands that are required for operation. 'wplext.library' will house any extension commands that might be usefull for WPL programmers, but who's usage in 'Config File Generators' will be discouraged in order to keep RAM requirements down. Please let me know if you disagree with my organization. (*) - indicates a 'wplcmd.library' command (+) - indicates a 'wplext.library' command (-) - indicates a temporary command that might be removed. (*)AddResponse PAIRS - Does not read or modify any variables. Takes a pair of parameters. The first is an 'event' name, and the second parameter is a pattern. Three special cases exist: a) The event is the word 'find'. In this case the second parameter is not a 'pattern', but is a string that contains a %d that will be used to find the baud rate. The matching is considered 'true' if the number is found. An example would be: Addresponse FIND "CONNECT %d" The event type as returned from GetResponse will actually be 'CONNECT', and the baudrate is changed to the number grabbed with the %d. b) The event is a number. In this case the second parameter is a case insensitive AmigaDos wildcard. If it matches the incoming string, the event is set to 'CONNECT', and the baudrate is changed to the given number. c) The even it just text, in which case the second parameter is a case insensitive AmigaDos wildcard. If the wildcard matches, the event is set to the value given by the first parameter. (*)Address 2 - does not read any variables - sets $(Result1), $(Result2), $(RC) The first parameter is a CASE SENSITIVE AREXX port name, and the second parameter is a command to be sent to that port. The result from the command is set into $(Result1). If the result was 0 and a secondary result was returned, it will be placed into $(Result2). Return values in $(RC) are as follows: 0 - Message sent OK. 19 - Couldn't find Port. 20 - Memory for message couldn't be allocated. (*)CallForward 1 - does not read any variables. - Sets $(RC) as a boolean. This command will take a call found with the 'CheckCall' command and will forward it to an alternate slave/message port. The parameter given, if it is a number, is taken to be the number of an active slave. Otherwise, the parameter is taken to be the REXX message port name of an active REXX host. If the port is found, the REXX message (Exactly as it was sent to this slaves port) is forwarded to that port, the 'active call' pointer used by 'ReportSesStat' is cleared, and the variable $(RC) is set to TRUE, otherwise $(RC) is set to FALSE (And the call is not cleared or forwarded). Note: If one wishes to re-queue a call to be processed at a later time, one would just forward it back to the same slave, eithor by REXX name or by saying 'CallForward $(line)'. Also note that the REXX port that this forwards the REXX message to can be *ANY* valid AREXX port on the system, not just the WPL ones. If one is running a mailer other that WPL, they could even forward a call to this other program's REXX port. (*)CheckCall 0 - Does not read any variables. - Sets the $(RC) variable as a boolean. Also sets the stem variable 'remote'. This command will check the call queue and will return the address information of the call (in the stem variable 'remote') and set the $(RC) to TRUE if a call exists. If there are no pending calls, $(RC) will be set to FALSE. The stem variable 'remote' includes: remote.address , remote.network, remote.domain,remote.zone, remote.net, remote.node, remote.point. The remote.address is a full nDimensional address as specified by Xferq. The remote.network is currently one of 'FIDO', 'UUCP', 'FQDA', 'TEXT' as per XferQ. (*)CheckCarrier 0 - Does not read any variables. - Sets the $(RC) variable as a boolean. This command is used to check to see whether or not there is a carrier present on a specific slave. (+)Clear NO LIMIT Will remove a WPL style variable from the list of variables. This command is equivalant to 'set <var> ""' (*)ClearResponse 0 - Does not read or modify any variables. Will clear all the response strings for a slave. (*)Cmp 2 - Does not read any variables. - Will set the RC variable as a boolean. This function does a case sensitive string compare on the two parameters. The two parameters must match character by character (Spaces included) in order to set RC to 'TRUE'. (*)CmpI 2 - Does not read any variables. - Will set the RC variable as a boolean. This function does a case INSENSITIVE string compare on the two parameters. The two parameters must match character by character (Spaces included) in order to set RC to 'TRUE'. (*)Connected 1 - Does not read or set any variables Takes as it's parameter a network address and will set up the 'outbound list' from xferq.library for that site. In the future it will take any number of parameters, each one being an AKA address to send the files for (an XferQ feature). (*)Delay 1 - does not read any variables. - Sets the $(RC) as a boolean. This is a low overhead command that will wait for the amount of seconds given in the parameter. It is intended for short delays during negotiation, and should not be used for extended timeouts. Use WaitEvent or GetResponse instead. (*)FindFreq 1 - Reads $(outbund) - Sets the return code $(RC) as a boolean Takes an address as the parameter and will look for 2-D or 4-D request files in the outbound directory. If found, it will add them to the outbound list and will return $(RC) as true. (-)FlushLog 0 - reads $(LogPort) - does not modify any variables. flushes current log via LogProc (Rexx port "$(LogPort)") Equivalant to: Address "$(LogPort)" "FlushLog" (*)GetInbound 1 - Reads: $(TryWazoo) , $(tryFts1) 'SayHello' reads WPL variables: host.wzdomain, host.sitename, host.sysop, host.zone, host.net, host.node, host.point, remote.password, host.wzcap, freq - wpl variables set: remote.zone, remote.net, remote.node, remote.point, remote.wzdomain, remote.domain, remote.password, remote.address, remote.wzcap, host.wzcap (Modified to chosen protocol), remote.sitename, remote.sysop, remote.product, remote.product_maj, remote.product_min, EVENT, FTS1, WAZOO Gets inbound (Someone called in) negotiation (Login, FTS1, YooHoo, etc) Value given as parameter is the timeout in seconds. $(EVENT) has the following values: "FTS1" - TSYNCH received - $(FTS1)==TRUE, $(WAZOO)==FALSE "GOTYOOHOO" - Hello greeting received OK. wpl variables set: remote.zone, remote.net, remote.node, remote.point, remote.wzdomain, remote.domain, remote.password, remote.address, remote.wzcap, host.wzcap (Modified to chosen protocol), remote.sitename, remote.sysop, remote.product, remote.product_maj, remote.product_min "EMSI" - "**EMSI_" string received - Full line of text in $(namebuf) "LOGIN" - Line of text in $(namebuf). If $(namebuf)=="bbs" then <esc> may have been hit twice. "CARRIER" - Carrier Dropped. "TIMEOUT" - A timeout occured. (*)GetOutbound 0 - Reads: $(TRYWAZOO) 'SayHello' reads WPL variables: host.wzdomain, host.sitename, host.sysop, host.zone, host.net, host.node, host.point, remote.password, host.wzcap, freq - wpl variables set: remote.zone, remote.net, remote.node, remote.point, remote.wzdomain, remote.domain, remote.password, remote.address, remote.wzcap, host.wzcap (Modified to chosen protocol), remote.sitename, remote.sysop, remote.product, remote.product_maj, remote.product_min, EVENT, FTS1, WAZOO Gets outbound (We called out) negotiation (Login, FTS1, YooHoo, etc) $(EVENT) has the following values: "NOANSWER" - No return character came back from the <space> <return> stage of negotiation "NOCLEAR" - Line didn't clear after banner. "CARRIER" - Carrier Dropped. "FTS1" - Two Consecutive 'C' or <NAK> characters received, indicating FTS1 transfer desired. $(WAZOO)==FALSE, $(FTS1)==TRUE "NOSYNCH" - Timeout before any negotiation successfull. "NOHELLO" - Remote didn't acknowledge our Hello Message. "NOYOOHOO" - Remote didn't send their Hello. "BADYOOHOO"- Recieved YooHoo was bad. "WAZOO" - YooHoo properly received. $(WAZOO)==TRUE, $(FTS1)==FALSE During a YooHoo sequence our "Hello" is sent. At that point the equvalant of the 'WazooRespond' is executed. Then their Hello is received, and the variables indicated in GetInbound for YooHoo are then set. (*)GetResponse 1 - does not read any variables. - Will set the variables $(LastResponse), $(Event) and possibly set $(BAUD) (If $(event) was CONNECT). This command makes use of the Response strings set up with the 'AddResponse' command. Will wait for a maximum of seconds given by the argument for a line of text (Which is then placed in $(LastResponse). The text is checked against the response strings and if a match is made, then $(EVENT) is set to the EVENT part of the response pair, otherwise $(EVENT) is cleared to "", or it's set to one of the internal events (Listed below). $(EVENT) NOMODEM - MOpen was not done before this command - it exited immediately OWNDEVUNIT - Someone else wants the device TIMEOUT - A timeout occured CARRIER - Carrier 'dropped' during command CONNECT - From Response ### or response find (*)Launch 3 - reads $(stack), $(priority) - sets $(RC) launches a slave where the three parameters are 1) Line Number - Number > 0 2) Slave name - This is a string (Max 100 chars) that is used as the REXX port name, and the CLI name for the process. 3) Label to start execution at. The new slave is executed with the stack and priority indicated in $(STACK) and $(PRIORITY). The return codes set in $(RC) are as follows: 0 - All OK so far. 1 - Can't create public port. 2 - Can't open timer. 3 - Can't allocate vars structure. 4 - Can't open xferq.library 99 - No memory in slave. 101 - No memory for structure. 102 - Error in new process launching. (*)ModemClear 0 - does not read any variables. - Sets the $(RC) as a boolean. This command will clear both the inbound and outbound serial buffers. Will set $(RC) to FALSE if this line did not have it's modem opened, otherwise it will be true. (*)ModemClose 0 - Does not read or modify any variables Closes modem previouly opened with ModemOpen (+)ModemInit 0 - Reads $(BaudLocked), $(InitWait), $(InitLoop), $(HangupString) , $(initString), $(Atten), $(Prompt) - Sets $(Baud) to the same value as $(BaudLocked). Sets the $(RC) variable as a boolean. This command goes into a loop that looks like the following: while I've looped less than $(initloop) times Is there a carrier? Send The $(HangupString) string othewise, Have we gotten an 'OK' from the modem last loop? If not Send The $(Atten) string otherwise Send the $(InitString) Wait for a maximum of $(InitWait) seconds for the $(Prompt) to come back from the modem. if we still have a carrier, or didn't get the $(Prompt), then loop. The boolean $(RC) is set to FALSE if a carrier still exists after the system tries to initialize the modem, otherwise it is set to TRUE. (*)ModemOpen 0 - Reads: unit, device, serflags, baudlocked - sets RC as a boolean Will open a modem on this slave using the settings in the above variables. Will automatically close an old modem that may have been opened previously. (*)Pattern 2 - Does not read any variables. - Will set the RC variable as a boolean. This function does a case insensitive amigados style pattern match on the two strings. The first string is the source string, and the second string is the AmigaDos pattern. Examples: Pattern "This iS a TesT" "this ???a test" returns TRUE Pattern "this ???a test" "This iS a TesT" returns FALSE Pattern "This iS a TesT " "this ???a test" returns FALSE Pattern $(some_Variable) "#(1|3|5|7|9)" returns TRUE if the WPL variable some_variable is composed totally of a string of odd numbers. Pattern $(remfile) "#?.REQ" returns TRUE if the WPL variable remfile has a string that ends in the letters '.req' (Such as an incoming file request!) (*)Print 1 - Does not read or modify any variabes. This command will print the given parameter to the slaves active status console as set by 'SetStatus'. (+)PutLog 1 - Does not modify any variabes. - reads $(CurrentLog), $(LogPort) variable sends text to current log via LogProc (REXX port "$(LogPort)"). Equivalant to: Address "$(LogPort)" "PutLog $(CurrentLog) <text>" (*)ReportSesStat 1 - does not read or modify any variables. Takes a numeric return code, and returns it as the status of the current call. (*)Send 1 - does not read or modify any variables sends an un-interpreted string out the current modem. (*)Set PAIRS Sets local WPL style variables. Pairs of 'variable' 'value' are accepted. (*)SetA 2 - Does not read any variables. - Sets the given stem variable. This command accepts a 'stem variable' as the first parameter, and an address string as the second. eg: seta remote 1:163/109 Would set the same variables as CheckCall would if someone did a 'call 1:163/109' The stem variable includes: <stem>.address , <stem>.network, <stem>.domain, <stem>.zone, <stem>.net, <stem>.node, <stem>.point. The <stem>.address is a full nDimensional address as specified by Xferq. The <stem>.network is currently one of 'FIDO', 'UUCP', 'FQDA', 'TEXT' as per XferQ. (+)SetBaud 1 - does not read any variables. - Sets $(Baud) and $(BaudLocked) to the value of the given parameter. Will also set the $(RC) variable as a boolean. This command will set the baud variables, and then attempt to change the device's baud rate. Will set $(RC) to FALSE if this line did not have it's modem opened, otherwise it will be true. (*)SetEnv PAIRS Allows one to set a global ENV: variable. Pairs of 'variable' 'value' are accepted (*)SetMailerFlags 1 - does not read or modify any WPL variables. Changes the General mailer flags for this slave. Options not specified here will be left un-changed. Please do not ever rely on the system 'defaults' for these values. Flag Value Meaning D Y Generate and send a Dummy poll packet. D N Do not generate or send a Dummy poll packet. D E Generate and send a Dummy poll packet only if no other files are to be sent. P Y Assume the first file received should be a .PKT and generate a unique packet name. (Not yet implemented) P N Leave the filename of the first file as the remote indicated it's name should be. Example: For FTS-1 sessions, one would use: SetMailerFlags "DY,PY" (*)SetPri 1 - Does not read or modify any variables. Will set the priority of a slave to the given value. For further information on this command, please refer to the AmigaDos shell command 'ChangeTaskPri'. (*)SetStatus 1 - does not read or modify any variables Will set the standard out of a slave to a given file specification. Many different error messages and runtime status information (As well as the output of the 'PRINT' WPL command) go to this file handle. Usually specifies a RAW: (+)SetUpdate 1 - does not read or modify any variables Takes a parameter that can be one of three types: "SetUpdate NULL" - Turns this feature off (default) "SetUpdate status" - Use the existing status window (Not reccomended) "SetUpdate <filename>" - Use the given filename (RAW: usually) for the XPR transfer status window. (*)SignalSlave PAIRS - does not read or modify any variables Given a slave number it will send the given signals to the slave. The signals are as follows: "c" - BREAKC "d" - BREAKD "e" - BREAKE "f" - BREAKF "m" - Message Port Signal Signals are most often sent to a slave in order to 'wake it up' to check other variables/etc. (*)SmartSend 1 - reads $(SlowModem) - does not modify any variables Sends interpreted modem string to the serial port. The interpreted characters are as follows (Note: one would preceed these characters with the '\' excape character if the special character needed to be sent out the modem): ^ - Raise DTR. See $(DTR_CONTROL) v - Lower DTR. See $(DTR_CONTROL) ~ - Wait 250ms. ` - Wait 62.5ms. | - Send a return character. If the variable $(SlowModem) is TRUE, a 62.5ms delay will be placed between each character sent. (*)System 1 - Reads the WPL variables: stack, ShowSystem - Sets the variable RC with the return code of the AmigaDos command. The WPL variable 'stack' is used to change the default stack (taken from the stack size of the slave itself). If the variable 'ShowSystem' is TRUE, the full 'execute' command is dumped to the status console. The command takes an AmigaDos function as the parameter and will synchronously execute the command. (*)XprClose 0 - does not read any variables - modifies $(RC) Ends session with XPR library and free's associated resources. The XProtocolCleanup() function is called, and any files left in the XPR transfer list are marked as having 'failed'. Any outbound management at end of session is handled. The variable $(RC) is set to false if the modem was not given, otherwise it is true. (*)XprReceive 1 - does not read any variables - sets $(RC) Receive single file (Specify name - Not yet supported) Receive batch files to $(inbound) (Specify "") This function will call the XPR receive function. During a transfer various WPL subroutines such as $(PostInbound), $(PreInbound), $(PostOutbound), $(PreOutbound) could be called. See "XPR Interface" section of the manual for more details. (*)XprSend 1 - does not read any variables - sets $(RC) Send single file (Specify name - not yet supported) Send batch files from list in outbound manager. (Specify "") This function will call the XPR send function. During a transfer various WPL subroutines such as $(PostInbound), $(PreInbound), $(PostOutbound), $(PreOutbound) could be called. See "XPR Interface" section of the manual for more details. (*)XprSetup 2 - does not read anyvariables - sets $(RC), $(XprSetup) Sets up an XPR library ready for a transfer. The first parameter given is the xpr library name, and the second parameter is a string passed to the xpr library with XProtocolSetup(). The variable $(XprSetup) is set to the numeric return of XProtocolSetup(). A value of 0 indicates a failure, otherwise the setup was successful. Since only one library can be opened at any one time, any previous libraries are first closed. Return values in $(RC) are as follows: 0 - All OK. 1 - XProtocolSetup returned FALSE. 2 - Library not able to be opened 3 - Out of memory. 4 - Wasn't given required modem. (-)WaitEvent 1 - does not read any variables - modifies $(BREAKT), $(BREAKC), $(BREAKD), $(BREAKE), $(BREAKF) The given parameter is a timeout in seconds. This command waits for any of the 4 signals and sets the appropriate boolean variable to 'true'. $(BREAKT) indicates that a timer event occured. During the wait the slave will process messages on it's REXX port. (*)WazooRespond 0 - Reads WPL variables host.wzdomain, host.sitename, host.sysop, host.zone, host.net, host.node, host.point, remote.password, host.wzcap, freq - Sets $(event) Used after a GetInbound to respond to the remotes hello packet with one of your own. Will read the listed variables to properly set the YooHoo hello. Possible values set to $(event) are: "CARRIER" - Carrier dropped. "NOYOOHOO" - Required response character not found. "2U2" - Success - Hello response sent. "TIMEOUT" - A timeout occured. --------------------------------------------------------------------------------- These commands exist for debugging/etc and are known to be being removed in the future (-)-ListResp 0 - Does not read or modify any WPL variables. Lists modem responses to console (from AddResponse). (-)-ListVars 0 - Doesn't change any variable. - Will list out all the active variables in a particular slave to the slaves console. (-)-ListConfig 0 - Doesn't change any variable. Lists out the current 'memory' version of the config file to standard out. (-)-Debug 1 - Doesn't change any variable. Outputs string to debug console via KPrintF() function (Sushi used to redirect). ------------------------------------------------------------------------------- The following commands are available exclusively from the REXX port. ABORT 0 This message, sent to a specific slaves message port, is intended to abort a specific slave. The REXX message will wait until the slave has exited before it will return. A WPL developer would check for the existance of an ABORT rexx message via the $<abort> calculated variable. CALL 1 This message, sent to a specific slaves message port, takes an address (Of any currently understood network type) and will add it to the list of sites that a specific slave will attempt to dial. This message will be replied to via the 'ReportSesStat' WPL which sets it's return code. Please see the documentation of the WPL instructions 'CheckCall', 'CallForward' and 'ReportSesStat' for further information. STRING 1 This message, sent to the specific slaves message port, is used to make use of the internal STRING generating routines. This message will return a message in RESULT (Make sure you have REXX set up with 'options results') which is the string created by sending the supplied parameter through the internal STRING handler. Any $(), ${}, $<> style variable substitution is available via this method and is a clean way to get information back from WPL. (Note: as an example, call.rexx makes use of this to check the status of a specific slave) ---------------------------------------------------------------------------- In order to facilitate standard features in all 'setups' of WPL, certain constructs are being strongly suggested to include. While these are optional, they will make interfacing with external programs written for use with WPL much more transparant. One of the issues relates to the use of the $(STATE) variable. Since Robert has been playing with this longer, I'll just add his latest thoughts: From: Robert Williamson on 1:167/104.0 Date: Friday, 25-Sep-92 22:38 (29-Sep-92) The WPL variable $(STATE) should be set to one of the following values. The values are case insensitive: WAITING Waiting for commands/waiting for ring/etc DIALING CheckCall to event CONNECT ANSWERING event RING to event CONNECT SESSION inbound or outbound session EXTERNAL system/rexx/login/bbs BUSY anything else EXITING obvious When reading $(state), the user should be aware that a string is returned, and in some implemeations only the first word of this string is one of the above. For example,in arexx, if doing a comparision, to be safe, one should : if upper(word(RESULT,1)) = "DIALING" then do ....whatever At present the Roof implemeation returns the following extensions: DIALING $(remote.address) SESSION [$(remote.address)|"unknown"] [INBOUND|OUTBOUND] SESSION unknown FTS1 SESSION [BBS|LOGIN] $(username) I'm setting BUSY from waitring: to just after setglobals in waitring1: where I set WAITING. In other words, modem stuff. I set ANSWERING at my own answer: label (entry point for answer when NO DIAL TONE on dial), just before sending answer string. For EXTERNAL, I save and restore the previous state. I've added an addtional in the Slave Startup, "LAUNCHING $(line)" I'm still refining this and may remove or add stuff. :) ---------------------------------------------------------------------------- Read-only Calculated variables: $<variable> There are a type of variable used in WPL strings that are known as calculated variables. These variables are variables who's values are 'evaluated' at the time that the value is asked for. Currently, the calculated variables are as follows: $<date> - substitutes the date in dd-mm-yy format. This will be localized at a future point. $<time> - substitutes the current time in hh:mm:ss format. This will be localized at a future point. $<abort> - Counts the number of REXX abort messages awaiting WPL to exit. This is used as a boolean that when true ( > 0) will signify that a WPL script should attempt to exit. These messages will be replied to only once the last slave has closed. $<slaves> - Counts the number of active slaves at any given point. ---------------------------------------------------------------------------- XPR Interface: During an XPR transfer, various WPL subroutines could possibly be called. These WPL subroutines are figured out at the time when XprSetup is called, and the variables should not be changed during an XPR transfer. They are subroutines, and thus one must do a RETURN to return control back to the XPR. It is intended for simple 'display' purposes and no large amount of logic should be done in these subroutines. *UNDER NO CIRCUMSTANCES SHOULD ONE OPEN OR CLOSE AN XPR DURING THESE SUBROUTINES* The subroutine variable names are as follows: $(PreInbound) - Called first time an Inbound file is opened. $(RemFile) - Filename as given by remote $(TempFile) - full pathname to temporary inbound name. $(FileSize) - The file size (from protocol, 0 if not known yet) $(PreOutBound) - Called first time an Outbound file is opened. $(RemFile) - Filename as given by remote $(LocalFile) - full pathname to local file. $(FileSize) - The file size (from disk). $(PreFullName) - Called first time a 'FullName' file is opened. $(RemFile) - Filename as given by remote $(LocalFile) - full pathname to local file. $(FileSize) - The file size (from disk). $(PostInbound) - Called after an Inbound files status is known. $(FileStatus)=="Received","Failed" $(RemFile) - Filename as given by remote $(TempFile) - full pathname to temporary inbound name. $(InFile) - Full pathname to final name (After rename if successfull transfer) $(FileSize) - The file size (from protocol) $(CPS) - Characters per second rating. $(CPSP) - Characters per second rating (Percentage) $(PostOutbound) - Called after an outbound files status is known $(FileStatus)=="Sent","Deleted","Truncated","Failed" $(RemFile) - Filename as given to remote (asname) $(localFile) - full pathname to local file. $(FileSize) - The file size (from disk) $(CPS) - Characters per second rating. $(CPSP) - Characters per second rating (Percentage) $(PostFullName) - Called after a 'FullName' transfer status is known $(FileStatus)=="Sent","Deleted","Truncated","Failed" $(RemFile) - Filename as given to remote (asname) $(localFile) - full pathname to local file. $(FileSize) - The file size (from disk) $(CPS) - Characters per second rating. $(CPSP) - Characters per second rating (Percentage) Mailing List: There is ongoing work with group in mailing list towards a possible XPR 3.0 specification. Some full bi-directional transfer will be worked on. To join the list, send an Email to: xpr-request@aldhfn.akron.oh.us with "subscribe user@site" as the body For posts to the list: xpr@aldhfn.akron.oh.us ---------------------------------------------------------------------------- Support Utilities ----------------- The latest versions of these utilities will be file requestable from the WPL support site, and the list is available via the magic name 'WPL'. JBundle - The latest release of JBundle (Jbun2.rexx) now makes use of XferQ to manage the outbound list. This script will take 4 dimensional zone.net.node.point.OUT files generated by many mailers and do all the required manipulations to compress and add the files to XferQ in a very multi-tasking friendly way. JTick - A grouping of REXX scripts and AmigaDos binaries to handle file echo distribution, file posting, and other related functions. Makes use of XferQ for outbound lists. Login - A program that allows Welmat/WPL to act as a 'getty'. Login takes a user name, and will prompt for a users password. If the password matches it will run the given command. Reads a password file very similar to a unix PASSWD file (Similar to the AmigaUUCP GETTY command). LogProc - a REXX message port host that handles multiple logging sessions. Currently used as logging system for many WPL based mailers. Lookup - A nodelist.library [Igen - a recompile is required for traplist support] based utility that will do a nodelist lookup and stick the results in environment variables in a form used by many WPL scripts. ROOF - Robert Williamson has written many usefull scripts including a full mailer in WPL, a 'download without having to log into the BBS', a WLint program to check WPL programs for correctness, a master files list program, and many more. The file ROOF_WPL.lha is in the WPL support files area, and is updated weekly. More up-to-date versions are available directly from it's author. xferq.library - WPL has now completely moved over to XferQ support, including all address handling. The 'seta', 'call' and 'connected' functions can accept any address type that XferQ itself can handle. WPL programmers should probably file request the complete XferQ documentation so that they can make use of the library and AREXX interfaces to this shared library in their software. XFreqSH - This is a replacement for the old WNotify program [which does not work with WPL any more] for use with XferQ based mailers. Source has been released to the public domain in the hopes that better file request handlers can be written, and that XferQ support will be added to the already existing file request handlers. XTool - This utility allows one to do the bare minimum queue maintenance with XferQ. It does replace most of the functionality of what FloAdd, FloEdit and FloList did for flow.library. xprclock.library - A sample library used to get set the Amiga's clock from an atomic clock such as the one ran by the NRC in Ottawa, Canada. Sources are released as a simple example to people wanting to write XPR libraries for non file-transfer usage. xprfts.library - Now documented in the separate archive, I am still looking for a volunteer to take over the development of this library while I take care of other things. The XPR Update handling is basically non-existant, and the display looks extremely poor during an FTS1 or DietIFNA session. xprzedzap.library - Yves is the current 'Keeper of Sources' to this library that is becoming very robust. The latest version I have seen was sent out as zzbin100.lha into ADSCOMM. ---------------------------------------------------------------------------- WPL Internals (For information purposes only) ------------- While there will be direct user access to many of the internals of WPL via a WPL Programmers Interface (WPI for short), this interface has not yet been standardized. In order to give potential developers an idea of the direction that we are headed, I will give a bit of documentation here. To start, one must first understand what happens when WPL loads a script into memory. While the language is an interpreted language like AREXX, unlike AREXX each command and parameters are tokenized as it is loaded so that the running of the script will be faster. The script is loaded, line by line, and analysed according to this very basic layout: [label:] WPL_Command [parameter1] [parameter2] It then first checks if the first character of the WPL_Command is a semicolon, and if this is the case the entire line (except the possible label) is thrown out. Labels are attached to the next valid WPL Command, so the following are equivalant: ; Comment label: WPL_Command label: ; Comment WPL_Command label: ; Comment WPL_Command The tokenizer will next look up the WPL Command in an internal list of commands to try to figure out it's 'token number'. An instruction token is just a simple unique 32-bit number. This number is specific to the revison of WPL currently running, and is also dependant on any WPL language extension libraries that might be attached to wpl.library. Once the token is found, attached with the token is a number that corresponds to the number of parameters that are required by the specific command. The specified number of parameters are accepted from the command line, and added into the instruction list element. One should note that extra parameters are just ignored, and not included in the parsed memory version of the instruction. Two special 'parameter numbers' exist, one to signify an unlimited number of parameters being accepted, and another to indicate that an unlimited number of parameter pairs are accepted. For those versed in the language 'C', the current internal instruction structure looks like the following: struct wProgNode { struct Node wp_Node; /* ln_Name points to label if exists, or NULL */ unsigned long wp_Size; /* entire size of this structure for free'ing purposes */ unsigned long wp_Inst; /* instruction number - language revision specific */ struct wProgNode *wp_Goto; /* address of possible label */ char wp_Args[2]; /* start of memory for arguments/label */ }; In the public structure when WPI is documented, the 'struct wProgNode *wp_Goto' will become 'void *wp_Data', and will be private to the instruction implementer. In the above, the wp_Goto is used to store a 'label' location the first time a *JUMP instruction is executed. The next time it hits the JUMP instruction, the command runs considerably faster. The 'char wp_Args[2]' will become 'char *wp_Args[]' and will be an array of 'pointers' to the character strings. The last element in the array will be a NULL pointer that will signify the end of the parameters. Currently a blank parameter is being used to signify the last parameter, and this causes major problems if one wants to pass the null string ("") as one of the parameters to an instruction. Currently funky magic comparing a pointer with (instruction+instruction->wp_Size) is being done, which is IMO not an appropriate way to handle things. Now, when an instruction is executed, the wp_Inst is used as an array index into a table of instructions, and from this table a pointer to the actual function is found. The generic prototype for an instruction is: void wi_Instruction(struct wProgNode *thisNode,slave *mySlave); All parameters are then extracted directly from the instruction structure. As an example, the simplest instruction in WPL would be the 'print' instruction, and it's code is as follows: void wi_Print(struct wProgNode *thisNode,slave *thisSlave) { WGetString(thisNode->wp_Args,thisSlave->scratch,SCRATCHLEN,thisSlave); PutStr(thisSlave->scratch); } Asside: If anyone ever wants to know the specifics of how an instruction is implemented, please just ask and I will send them the code for that instruction. Note: 'slave *' is a general pointer to a structure who's internal composition is not available to a WPL instruction. It is a 'cookie value' that is passed to most WPI interface functions. Inside of a function, it is allowed only to access other parts of WPL through the WPI interface. An exception to this would be the 'built in' instructions such as the *JUMP commands which have intimate knowledge of the internals of WPL beyond the definition of a wProgNode, and the interface functions defined with wpl.library. Here is a list of ideas. I will likely not complete all of these before making a preliminary release, and all documentation on these will be subject to change as the need arises until the first 'totally public' release (At which time anything that is documented will have to be cast in stone!). I will be expanding this documentation as time permits to express current design ideas. - Command ideas: Group-I: - XPR defined calls. These calls will have exactly the same structure as the XPR callback functions, except that they are accessed as library calls, and the additional parameter of 'slave *' is also passed. One should note that the XPR callbacks within WPL are just simple assembly stubs that in one way or another will obtain this slave pointer. These functions are defined and expanded as XPR is expanded. See the XPR documentation for more information. wpi_fopen() Open inbound/outbound file wpi_fclose() Close file wpi_fread() Get string from file wpi_fwrite() Put string to file wpi_sread() Get string from serial wpi_swrite() Put string to serial wpi_sflush() Flush serial input buffer wpi_update() Update file transfer status wpi_chkabort() Check for abort wpi_chkmisc() Check misc. stuff wpi_setserial() Set and Get serial info wpi_ffirst() Find first file name for batch transfers wpi_fnext() Find next file name wpi_finfo() Return file info wpi_fseek() Seek in a file wpi_unlink() Delete a file wpi_squery() Query serial device wpi_getptr() Get various host ptrs Future XPR defined functions that may be implemented. wpi_gets() Get string interactively wpi_options() Better GUI based option requesting. Group-II - Variable control wpi_getstring() Get WPI variable replacement string. wpi_setvar() Set a variable to a null terminated string value. wpi_getvarnum() Returns a long integer value from a variable. wpi_setvarnum() Set a variable to a given long integer. wpi_getvarbool() Returns boolean value of variable. wpi_setvarbool() Sets a boolean variable. (Strings "TRUE":"FALSE") Group-III - WPI control wpi_findslave() Returns a 32-bit value defining the slave - Number given is slave number, or NULL - NULL will find the slave who's process we are currently running within (For libraries). wpi_controlTags() Generic interface to various internal controls. The interface to allow the adding of various transfer status GUI handlers, Handlers for additional REXX based commands, WPL language extensions and other related functions will be supported. wpi_docmd() Executes a single WPL command. wpi_execscript() Runs a WPL script in the current context - Must be a 'Slave' context executed from within a WPL extension library. wpi_launch() Launches a new Slave. wpi_loadscript() Loads in a WPL script ready to be executed (Multi-file scripting support) ---------------------------------------------------------------------------- Bug Reports ----------- WPL is in many ways a series of atomic commands that can be put together via a configuration script. When filing a bug report, please break the report down to it's smallest componants. For most reports, the problem can be broken down to being a single WPL command. A bug report where you list your entire configuration file and say "It doesn't run" is likely going to be met with silence as it's not all that usefull of a report. As an example, if a problem is with a boolean *JUMP command, what one should report is the exact value of the $(RC) and the type of *JUMP command used. Please verify that the target label can be found by replacing the *JUMP by a non-boolean JUMP instruction, and check if the branch is taken in this situation. For 'label' based problems, the output of the -ListConfig command is very helpfull. I would expect the output of this command in a bug report, and not a duplicate of your text configuration. What -ListConfig will do is output the 'already parsed' memory copy of the configuration file. My sample configuration file does this for you. Also note that for a problem to be fixed, I have to be able to duplicate it on my own machine. If I can not duplicate it, it is impossible for me to even begin to look into the problem, so please give as clear and consise a report as possible so that I can find a way to duplicate the problem. - Null Labels (A ':' on a blank line) was reported to crash the machine. (Unverified - I could not duplicate the problem) - xprfts.library transfers have an un-reliable startup for file sends - line noise can cause the transfer to be aborted. (Verified) - Robert reports odd problems with the boolean *JUMP commands. (Unverified) - Odd "Can't open file" when inbound $(inbound) changed just before zedzap transfer. [Yves mentioned it might relate to attempts to send '0 length files', ulthough I don't see how that relates to the changing of the $(INBOUND) directory as that would only be relevant to inbound (write) files] (Unverified) - System crashes while loading for the first time. I'd like to have people do more testing on this as I'd like to get this one fixed before moving WPL into wpl.library. (Unverified) - Some part of the passing mechenism of information between AREXX and WPL is limited to '50 characters'. I need much more information to go on before this can be looked into. - Very likely there are memory problems with LogProc. Problems where two 'abort' messages must be sent to LogProc exist. The program was written a long time ago, and no large amount of debugging has been done. If anyone has some time, and is very familiar with EXEC lists, please let me know. - Bug where one has to do an 'abort' request twice before the logging system actually aborts (Verified). TODO LIST --------- Here are some ideas that will be worked on towards V1. This list is not complete, and I would appreciate people listing anything that I have not included in this list. Some issues may not get dealt with before the release of Version 1 but will be dealt with in later versions. I have only started to set up an order to this list. - 'SetMailerflags PY' is listed as not yet implemented. - Document XPR issues (Security, level of expansion above XPR 2.0, compatability) - specifically mention 'unknown' filenames, and their default to being 'inbound' files in the $(INBOUND) directory. - Path names are always stripped from the XPR's idea of the filename. - XprSetFile - Allows a pathname/asname/type mapping to be user configured so that one could do their own resume handling, or sending of a file with a different name to the remote site without adding to the outbound handler. Used to indicate full pathname of single file sends. XprSetFile <Full Path Name> <Remote/AsName> <File Type> Where file Type is any of: o - Outbound file. d - delete file after sending. t - truncate file after sending. i - inbound file. Eg: XprSetup xpftext.library "" XprSetFile work:text/TheWarOfTheWorlds.txt twotw.txt o XprSend twotw.txt XprClose - Address list handling - Most functions that take an 'address' as a parameter will be updated to take an address list. For the purpose of the 'stem.ZONE', 'stem.NET', etc the first FTN address in the list will be used if an FTN address exists at all. - Clean things up so that all addressing defaults are taken from the defaults in Xferq (Currently Xferq:hostaddr) rather than being hard coded (ef: Wazoo domain 'fIdOnEt') - All methods to launch a slave, including the WPL 'Launch' Command updated to be the same syntax as the C and REXX counterparts. Launch PortName Slave# StartLabel Priority Stack - wpl.library - The main slave handing parts of WPL will be moved into a shared library. This will allow for external access to some of WPL's internal functions in a standardized method. Launching/Exiting slaves, WPL variables, slave serial/io, and many other things will be accessable through this library. Many functions will be accessable to the AREXX user through this library as well. *NOTE* The main binary 'WPL.bin' will no longer exist. One would launch WPL scripts via the wpl_launch() function (Which will be accessable via AREXX). pseudo-C for 'WPL.bin' emulation: main(int argc,char **argv) { char scratch[128],*script; long ret; Library *WPLBase; if(!(WPLBase=OpenLibrary("wpl.library",0)) { printf("Couldn't open WPL - exiting\n"); exit(200); } if (argc>1) { script=argv[1]; } else if(GevVar("WELMAT",scratch,128,0)>0) { script=scratch; } else { script="welmat.lng" } if(ret=wpi_loadscript("main",script)) { /* script name, filename */ printf("Script loading error: %ld",ret); } else if(ret=wpi_launch("SUPERSLAVE",666,"MAIN!STARTUP",0,30000)) { /* Name,number,"script!label",priority,stack */ printf("Slave Launch failed return code %ld",ret); } else printf("WPL slave launched"); CloseLibrary(WPLBase); exit(ret); } - Multi-file WPL programs for easier writing. As indicated in the above, I am thinking of having labels expanded such that the 'script name' can be specified with any *jump command. The '!' symbol would be used to separate the script name and the label. EG: wpl script name: main ... SubJump thispart TrueSubJump mybbs!startup ... thispart: cmpi $(username) "BBS" return wpl script name: mybbs startup: send "Welcome to my WPL based BBS" ... - Asynch SYSTEM command so that REXX messages can be received while a command is executing. - GetInbound/GetOutbound commads updated to understand the **EMSI_INQ and **EMSI_REQ negotiation sequences. New $(EVENT) sequences will be: EMSI_REQ - A proper EMSI_REQ was received. Remotely called site is EMSI capable. EMSI_INQ - A proper EMSI_INQ was received. Calling system is EMSI capable. EMSI_BAD - An unknown or bad EMSI sequence was received. Full line of text starting with **EMSI_ stored in $(namebuf) for possible additional processing. New boolean variables read: GetFTS1 - Scan for double 'C' or double <NAK> in GetOutbound, Scan for TSYNCH character in GetInbound. DoFTS1 - Send TSYNCH character in GetOutbound. GetFTS6 - Scan for ENQ in GetOutbound, Scan for YOOHOO character in GetInbound. DoFTS6 - Send YOOHOO character in GetOutbound GetEMSI - Scan for any EMSI Sequences in both GetInbound/GetOutbound. DoEMSI - Send an EMSI_INQ during GetOutbound as part of negotiation. May cause negotiation problems with non EMSI sites and should not be required. More complete EMSI Supported with the addition of a 'SendEMSI' and 'GetEMSI' functions: - SendEMSI will take the EMSI sequence name (EG: "IRQ") as it's parameter. Different EMSI sequences will read different WPL variables depending on the sequence. - GetEMSI will take a timeout. $(EVENT) will be set to the received EMSI sequence. Various variables will be set depending on the EMSI sequence received. Here are the origional notes on EMSI that describes some of the issues: Before the final release of WPL V1, a fully extendable handshaking method will be implemented that will allow for full n-dimentional addressing, allow for non-fidonet addresses, unlimited AKA's, and unlimited support for user definable protocols. Since I only wish to add a single handshake, I do not wish to add a new handkshake unless it totally suits the needs of WPL. While the current EMSI specification has most of what would be required, a few limitations still exist: a) The concept of an 'address' is not clearly specified within the handshake. While it makes reference to FTS-0001 for an out-dated 4-D format for a fidonet address, it does not state a fully 5-D fidonet address, or state that one should 'skip' any addresses that are not understood. (An 'address' can be thought of as a stream of characters separated by spaces, and terminated by an non-escaped '}' character). [ADDENDUM: The fidonet format of zone:net/node.point@domain is being documented as the standard for EMSI. Further documentation on non-fidonet addresses such as 'atronx.ocunix.on.ca' are also going to be mentioned] b) Zmodem has been named the 'minimum protocol'. Since 'Fidonet' policy already dictates that all sites within the 'Fidonet' nodelist must already handle the FTS-1 protocol, I'm not going to add yet another 'requirement' to WPL users. WPL users should be able to pick and choose the protocols that best suit their networking environment, and in many cases Zmodem is a poor choice (Expecially outside of a nodelisted environment where one should only be required to keep online a small group of common protocols). Regardless of one's opinions on Zmodem (Or any other protocol for that matter), it should still be left up to the users to make that decision. [A kludge called 'SLK' to support SeaLink has been added. While this adds an additional protocol to the list being supported, it does not address the origional issue at all. I am going to just ignore this and document my use of a flag to indicate DietIFNA] c) Related to the second issue is the fact that EMSI doesn't define a method to 'fall back' to an alternate handshake if EMSI fails. Since both FTS-1 and FTS-6 (YooHoo) allow for protocols that are not yet shown in an EMSI handshake, there are sites where one would call where an EMSI handshake would fail, but an FTS-6 (Or even FTS-1) handshake would be successfull. Unless a REQUIREMENT of EMSI is that all protocols that a program supports be shown in the EMSI handshake, then a method to fall-back to an alternate handshake protocol is required. Personally, the better solution would be to require all transmission protocols to be shown, but there are those that argue against this possibility. [While a fallback method is being documented, JoHo (author of FrontDoor) has already stated that he does not plan to support it in the next release of FrontDoor. Again, this oversight on JoHo's part is just going to be ignored] The EMSC group is currently discussing an update to the FSC-0056/EMSC-001 document that will address these issues. It's unfortunate that the EMSC group does not see the EMSI handshake as being the independant handshake that it could have become and placed these limitations on it, but I think that 'common practise' can outweigh the limitations. I will be documenting a list of protocols and 3 letter EMSI ID's to use for all the available XPR protocols. I will also be constantly sending an updated list to the EMSC group and into the NET_DEV conference and I think that one by one the various authors will start to support these various protocols regardless of what the EMSC group tries to limit the EMSI protocol to. - Finish up the XPR interface and set up some of the new XPR 3.0 ideas. Asynchronous File i/o (xpr_fwrite(),xpr_fread()) need to be written to increase transmission speeds. Double-buffered xpr_swrite() call will also be set up. ** Document and release WPL V1.0 (Privately unless some WPL 'applications' are available at this time), a preliminary 'WPL developers Package' from which various applications can be written. - WPI interface - Many third party function libraries will be made possible by a standard method of adding commands to the WPL language via routines provided by wpl.library (See wpi_addfunclib()). The main library itself will only contain commands that cannot be made external, and all other commands in a WPL extension library. - WPL internal tokenizer updated so that internal parameter passing is changed from a stream of null terminated strings to a NULL terminated array of strings. - WPL <-> FPL interfacing library. A new language that has all the looping, boolean conditions and other such constructs has been written and made available in the form of a library. I will be attempting to write an interface library (See wpi_getfunclist()) so that people could write their mailers in a more full functioned language such as FPL (All WPL commands except the 'control' constructs such as labels and *JUMP commands will be available, much like the current AREXX interface - The speed of WPL will likely be considerably faster than AREXX). - Expunge handling in wpl.library in such a way that the WPL system will minimize memory usage when WPL is not actually in use. This will be very usefull to BBS operators in low-memory situations. - File resume handling using some sort of standard filenote format. If other formats are desired by a WPL developer, the XprSetFile command would be used to manipulate with any other format. - A WLint to verify correctness of WPL programs, and to aid in writing. Checks for the existance of labels, accessability of labels, syntax of commands (Number of arguments, etc). A simple REXX script has been written by James Atwill as a beginning called wpllc.rexx. - WCompile/WConfig for a config file similar to the Welmat V0 config file. This will be for the 'middle' type users. WConfig would allow the reading/writing of V0 config files, but have a GUI for ease of configuration. - WPLPrefs for use by point operators. This will be totally point and click with a minimum amount of information required from the user in order to configure and run WPL. This will set up an 'icon' that a user would just double click on in order to call their bossnode (More than one Icon will likely be required for more than one bossnode). NOTE: It is my hope that WCompile/WConfig/WPLPrefs/etc/etc will be written by separate groups from myself. I would rather spend my time on lower level tool development and have the 'application level' programs written by different authors. - xprfts.library - Needs to be fully debugged and updated to use the XPR Update screen. This could easily be done by a third party author as all souces for this library are released. If anyone has some time, please let me know! - xprscript.library - A full (And faster than implementing within WPL) scripting language. Please send suggestions (Or even complete lists of requested scripting commands) to myself. If there is a 'most popular' scripting language (VLT maybe?) that the author of the origional would not mind me implementing, I might go for that. The basic 'Send/Expect' as used in UUCP will of course be implemted as a subset of the commands. (P.S. Jason Trimble has donated a 'Style Guide' to the WPL project, and I have been told that the beginnings of a scripting language is documented in there. This will likely be the starting point for the scripting language). - OwnDevUnit - When ModemOpen cannot open a modem because someone else has it locked, it will be possible to run a WPL function that will be given the text of who has the device locked. If this function returns with $(RC) set to TRUE, then ModemOpen will wait, otherwise it will abort ModemOpen with a failure. - ReportSesStat expanded to be able to set the rm_Result1 (Usually called RC in a REXX script) as well as rm_Result2 (Usually called RESULT in a REXX script). It currently only sets rm_Result1. - Allow a ctrl-C in a slaves status window to abort an XPR transfer. - Deal with standardizing the use of the standard CTRL_C, CTRL_D, CTRL_E, and CTRL_F signals throughout all of the WPL commands. - Cliplist reading within WPL variables. While I know how to set variables, I'm not at the moment sure how to read them. This idea may be scratched. - A full xprfts7.library with full resume, SLO, etc - Expand variable sub-system to allow for deleting of entire stem variables with a single command. - IdentARing, Caller-ID and full voicemail support for use with the ZyXEL U-1496 modems. CallerID is already in use in some WPL scripts. - IEMSI terminal specification for use with WPL based BBS's (And possibly others as well, depending on external support). This could build into a full auto-login, fully graphical BBS Users interface with background file transfers/etc/etc. Issues: - Calculated Jumps - Jumps that involve a variable name within the parameter. - advantages - Allows for 'self modifying' code - disadvantages - Allows for 'self modifying' code (Sorry, I had to say it) - slows down as *JUMP commands usually make use of a label location cache that is not possible with labels that can change. - Adds more complication to scripts with no way to do a 'lint' that would verify the validity of scripts before runtime - More runtime errors. - AbortAll - I believe that any WPL script that launches slaves should keep a list of these slaves, and if someone requests that they be Aborted, that the WPL script do it itself (Via the 'address' command). I do not want an AbortAll command to ever be implemented as this would mean that one 'slave' could arbitrarily kill off slaves that might have absolutely nothing to do with handling of modems, or with the WPL script that seems to want to abort things. - Distribution - Should the WPL development documentation be distributed with an 'application', or should the two be kept separate. I myself would love to get to the point when I am just supporting the WPL developers, and these developers are supporting their own applications. Is this possible? In this case the WPL development distribution could contain some 'examples', but this package would not be what is sent out to the 'public'. It also would avoid some of the 'multiple version' issues if a WPL developer released the specific version of WPL and support utilities required to run their application. - Support conferences - I am currently trying to set up a separate 'WPL_APPLICATION' support conference to replace 'WELMAT' which is currently on the backbone. I would like to move the developer support (The majority of what is currently happening in the 'WELMAT' conference) into a separate conference, WPL_DEVELOPMENT. How open this conference will be (Private, Backbone, Gated to Usenet?) is up for discussion. Whether or not 'heavy techie' will be allowed in the 'WPL_APPLICATON' conference, and whether a new moderator will be named is also up for discusion. Again, I think the WPL_APPLICATION are should be moderated by someone other than myself.